Bun.serve: copy the request head out of the receive buffer before the event loop runs again - #42791

Reproduction, on 1.4.3-canary.1 (09bb546) and on this branch's debug build:

// handler 1 runs the loop, then reads its own head
second.write(head("2222222222222222"));
Bun.build({ entrypoints: [entry], plugins: [{ name: "p", setup: () => pending }] });
console.log(req.url, req.headers.get("authorization"));

• stock: http://h-2222222222222222.example/u-2222222222222222 Bearer au-2222222222222222
• fixed: http://h-1111111111111111.example/u-1111111111111111 Bearer au-1111111111111111

Shape of the registry (src/uws_sys/Loop.rs). RecvBufferBorrow is a stack node on an intrusive thread-local list. unsafe fn register(&mut self) links it and returns a guard that unlinks it. The &mut stops a second registration of the same node at compile time. The unsafe contract is that release(owner) stays sound to call until the guard drops, and that guards drop in reverse order. Every caller registers a frame-local guard, and dispatch frames nest, so the guard unlinks with a plain pop.

Entry points checked by reading the code, all of which reach one of the four Loop methods:

• EventLoop::wait_for_promise (src/jsc/event_loop.rs) runs tick() then auto_tick(), and auto_tick (src/runtime/jsc_hooks.rs) calls Loop::tick_with_timeout or Loop::tick_without_idle. This covers Bun.build plugin setup (JSBundler.rs:589), async macros (Macro.rs:846) and expect().resolves.
• AnyEventLoop::tick_raw (src/event_loop/AnyEventLoop.rs:138), which the resolver's auto-install wait uses, runs the same tick() plus auto_tick() pair.
• MiniEventLoop::tick_once / tick_without_idle call Loop::tick / Loop::tick_without_idle.
• The raw us_loop_run re-export is used only by BundleThread's waker, which has its own loop and its own buffer. On Windows the only other direct uv_run callers are the Worker teardown drain and the thread-exit loop close.

The hook is on the Rust wrappers and not on the loop's pre callback because on Windows uv_run processes completed requests, which includes socket reads, before it invokes prepare handles.

The auto-install entry was also checked with a running build. A handler that require()s an uninstalled package reads /1.1 200 OK\nconten as its url on stock bun: the clobbering read was the HTTP response to another request on the same loop. On this branch it reads its own url.

A head pipelined on the same connection overwrites the buffer the same way, and the fix covers it (checked with a script). It is not in the test file because uWS does not dispatch that second request inside the nested run, so there is no event to wait for and the test would need a sleep.

to_async_without_abort_handler now calls Request::detach_uws_request_head instead of repeating the copy inline, so one function owns the copy. RequestContext::set_pathname carries the development-mode gate that to_async had inline. The early release calls it too, because the uWS request that the error-page formatter falls back to is detached by then.

Pre-existing failures in the suites above, unrelated to this change (they fail the same way on 1.4.3-canary.1): serve.test.ts "should use correct error when using a root range port(#7187)" and "only serves /bun:info to loopback clients in development mode", bun-server.test.ts "allows listen on IPV6". Several websocket-server.test.ts cases time out at 10 s when the whole file runs on a debug + ASAN build in this container and pass in about 1.4 s each in isolation.